home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-04-20 | 119.5 KB | 4,143 lines |
-
- Network Working Group C.Partridge
- Request For Comment: 1024 BBN/NNSC
- G. Trewitt
- Stanford
- October 1987
-
- HEMS VARIABLE DEFINITIONS
-
- STATUS OF THIS MEMO
-
- This memo assigns instruction codes, defines object formats and
- object semantics for use with the High-Level Monitoring and Control
- Language, defined in RFC-1023.
-
- This memo is provisional and the definitions are subject to change.
- Readers should confirm that they have the most recent version of the
- memo.
-
- The authors assume a working knowledge of the ISO data encoding
- standard, ASN.1, and a general understanding of the IP protocol
- suite.
-
- Distribution of this memo is unlimited.
-
- INTRODUCTION
-
- In other memos [RFC-1021, RFC-1022] the authors have described a
- general system for monitoring and controlling network entities; this
- system is called the High-Level Entity Management System (HEMS).
- This system permits applications to read and write values in remote
- entities which support a simple query processor.
-
- In this memo we standardize the language instruction codes, the
- objects which can be read or written, and the meanings of any
- constants stored in the objects. There are three parts to this
- standardization: (1) the assignment of an ASN.1 tag to each value,
- (2) the definition of the external representation of the value (e.g.,
- INTEGER, OCTETSTRING, etc.), and (3) the definition of the meaning,
- or semantics of a value (e.g., what types of packets a particular
- packet counter actually tracks).
-
- This definition is provisional, and the authors hope that it will be
- expanded and improved as the community becomes more experienced with
- HEMS. Readers with suggestions for additional object definitions, or
- improved definitions are encouraged to contact the authors.
-
-
-
-
-
-
- Partridge & Trewitt [Page 1]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- MESSAGE FORMATS
-
- All HEMS values are conveyed between applications and entities using
- the High-Level Entity Management Protocol (HEMP) specified in RFC-
- 1022. All values specified in this memo are passed in the data
- sections of HEMP messages. For all message types, the data section
- is a SEQUENCE of objects. For requests, these objects are operations
- and their operands. Replies contain a sequence of objects retrieved
- by a request. Events contain an initial event object followed by an
- optional number of objects related to the event.
-
- Messages conforming to this memo should set the link field in the
- HEMP CommonHeader to 1, to indicate version 1 of HEMS. The
- resourceId field should be set to NULL.
-
-
- CONTROL LANGUAGE INSTRUCTIONS
-
- The HEMS Monitoring and Control Language defines a suite of
- operations which the query processor must be able to perform. These
- operations and their operands are ASN.1 objects which are passed to
- the query processor over a network connection. The operations and
- operands are sent in postfix form (the operation follows the
- operands). Operands are pushed onto a stack and are processed when
- the operation is encountered.
-
- To ensure that operations are easily recognized in the input stream,
- they are all encoded in a single application-specific type. This
- type is shown below.
-
- Operation ::= [APPLICATION 1] IMPLICIT INTEGER {
- reserved(0), get(1) begin(2), end(3),
- get-match(4), get-attributes(5),
- get-attributes-match(6), get-range(7),
- set(8), set-match(9)
- }
-
- When the query processor encounters an Operation object it consults
- the value to determine which operation is to be done (e.g., GET).
-
- GENERAL COMMENTS ON OBJECTS STORED IN ENTITIES
-
- The High-Level Monitoring and Control Language requires the object
- space to have a tree-shaped type space. Locating a particular object
- requires identifying that section of the tree in which the object
- resides. (A more detailed explanation of the scheme is given in
- RFC-1023).
-
-
-
-
- Partridge & Trewitt [Page 2]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- This memo defines a universal type space. A subset of this type
- space is expected to be an appropriate type space for any entity
- (e.g., a gateway or a multi-user host). The type space is divided
- into required and optional portions. Implementors should implement
- the required portion of the type space plus that part of the optional
- type space which is appropriate for their particular entity.
-
- One problem with defining a universal type space is that certain
- interesting objects are not universal, but are instead very machine
- specific (for example, status registers on specialized hardware). To
- allow implementors to retrieve such implementation-specific objects
- using the HEMS system, a special APPLICATION type is reserved for
- non-standard values.
-
- Putting objects in ASN.1 form implies an ability to map to and from
- ASN.1 format. One of the design goals of this system has been to
- minimize the amount of ASN.1 compilation required by the query
- processor to reduce the expense of processing queries at entities.
- (This implies a certain willingness to force the applications
- querying entities to be more powerful). We expect that most of the
- complex mapping will be done when objects are read; most writable
- objects have a simple format (e.g., an INTEGER, or OCTETSTRING). As
- a result, we have made a heavy use of the ASN.1 SET type, which
- allows values to be presented in any order. Applications which
- require particular fields in an object may use the template structure
- to specify particular fields to be retrieved, but this still permits
- the query processor to return the fields in whatever order is
- convenient.
-
- In addition to ease the problems of ASN.1 compilation, query
- processors are not required to reduce an INTEGER to the minimum
- number of octets as specified in ASN.1. Applications should be
- prepared to receive INTEGERs which have leading octets with all zeros
- or ones.
-
- More generally, a design goal of HEMS was to try to limit the data
- processing done at the entity, and to place the burden of data
- reduction on the querying application. As a result, the objects
- presented here are typically counters, or values which the entity has
- to compute already. Object definitions which require the entity to
- do data reduction are not supported, although consideration might be
- given to making them optionally available.
-
- Finally, HEMS is required to support access by multiple network
- management centers or applications. This constraint has some
- important consequences. First, the SET operation cannot be applied
- to any Counter, since changing the value of a Counter may impair data
- acquisition by other centers. More generally, there are questions
-
-
-
- Partridge & Trewitt [Page 3]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- about competing or clashing SET requests from management centers.
- Currently HEMS does not provide any facilities for protecting against
- such requests. If such facilities become necessary, the authors
- envision the enhancement of the object definitions to incorporate the
- idea of "owned" objects.
-
-
- READING THE OBJECT DEFINITIONS
-
- Most of the rest of this memo is devoted to ennumerating the objects
- managed by the query processor. Many of these objects are
- dictionaries, objects which reference other objects. Defining
- dictionaries requires that we specify the class of objects they
- reference.
-
- Most significant objects, such as packet counts, reside at the leaves
- of the object data tree. They need to be carefully defined to ensure
- that their meaning is consistent across all HEMS implementations.
- These values are defined using the following format:
-
-
- OBJECT: This is the name of the object.
-
- Type: This is the ASN.1 type of the object.
-
- Definition: The meaning of the data the object contains.
- Implementations should ensure that their instance of
- the object fulfills this definition since an important
- feature of HEMS is that objects have consistent meaning
- across all machines. It is better not to implement
- an object than to abuse its definition.
-
- Notes: An optional section of the definition which is used
- to discuss issues not covered in other sections of
- this specification.
-
- Object Status: An optional section of the definition which
- is used to indicate whether the object is required of all
- HEMS implementations, encouraged of HEMS implementations
- or simply considered useful. Currently, there are four
- levels of status:
-
- Required: The object is felt to provide critical
- information and must be included in a fully
- conforming HEMS implementation.
-
- Required On Condition: The object is felt to
- provide critical information about an optional
-
-
-
- Partridge & Trewitt [Page 4]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- feature of an IP entity (for example, support of
- the Transmission Control Protocol). The object
- is required if the feature is implemented in the
- entity.
-
- Encouraged: The object is felt to provide very
- useful management information and implementors
- are encouraged to implement it.
-
- Defined: The object may be useful and has been
- defined so that all implementations of the object
- are consistent.
-
- If the object status is not specified, the object should
- be considered required. If the parent dictionary is optional,
- then the object should be considered required if the parent
- dictionary is supported.
-
- Operations on Object: The definition of how each monitoring
- and control operation acts on the object. Many operations
- have the same effect on almost all values, so some
- default definitions are presented here. In the absence
- of an operation specification, implementors should use
- the default operations defined here.
-
- BEGIN: The default is for BEGIN to be defined for
- dictionaries, and an error if performed on leaf
- objects in the tree.
-
- CREATE: The default is that CREATE is undefined.
-
- DELETE: The default is that DELETE is undefined.
-
- END: END is a stack operation and is defined for all objects.
- Note that END may fail if there is no object on the
- stack.
-
-
- GET-ATTRIBUTES: The default is that GET-ATTRIBUTES is
- defined on the contents of all dictionaries specified
- in this memo. The text description attributes
- are optional for values defined in this memo, but
- are required for implementation-specific objects.
- Any descriptions of object listed in this memo should
- cite this memo. GET-ATTRIBUTES must be supported on
- all entity-specific values. GET-ATTRIBUTES
- returns a Attributes object, which is defined in
- the well-known types section below.
-
-
-
- Partridge & Trewitt [Page 5]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- GET-ATTRIBUTES-MATCH: The default is that
- GET-ATTRIBUTES-MATCH is optionally defined on any
- object which supports GET-MATCH, and is an error
- otherwise. The rules for attributes returned by
- GET-ATTRIBUTES-MATCH are the same as those for
- GET-ATTRIBUTES.
-
- GET: The default definition of GET is to emit the operand
- specified is a leaf object, and if the operand is a
- dictionary, to recursively GET the entire dictionary and
- its subdictionaries.
-
- GET-MATCH: Unless otherwise specified, GET-MATCH is not
- supported on an object.
-
- GET-RANGE: Unless otherwise specified, GET-RANGE is not
- supported on an object.
-
- SET: Unless otherwise specified, SET is not supported on an
- object.
-
- SET-MATCH: Unless otherwise specified, SET-MATCH is not
- supported on an object.
-
-
- ATTRIBUTES
-
- HEMS requires that remote applications be able to discover the
- meaning of an object by querying the entity in which the object is
- stored. This is done through use of the GET-ATTRIBUTES operator,
- which causes an Attributes object to be returned to the application.
- The Attributes object is described below.
-
- Attributes ::= [APPLICATION 2] IMPLICIT SEQUENCE {
- tagASN1 [0] IMPLICIT INTEGER,
- valueFormat [1] IMPLICIT INTEGER,
- longDesc [2] IMPLICIT IA5String OPTIONAL,
- shortDesc [3] IMPLICIT IA5String OPTIONAL,
- unitsDesc [4] IMPLICIT IA5String OPTIONAL,
- precision [5] IMPLICIT INTEGER OPTIONAL,
- properties [6] IMPLICIT BITSTRING OPTIONAL,
- }
-
- The meanings of the various attributes are given below.
-
- tagASN1: The ASN.1 tag for this object.
- This attribute is required.
-
-
-
-
- Partridge & Trewitt [Page 6]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- valueFormat: The underlying ASN.1 type of the object
- (e.g., SEQUENCE, or OCTETSTRING). This attribute
- is required.
-
- longDesc: A potentially lengthy text description which
- fully defines the object. This attribute is optional
- for objects defined in this memo and required for
- entity-specific objects.
-
- shortDesc: A short mnemonic string of less than 15 octets
- which is suitable for labelling the value on a display.
- This attribute is optional.
-
- unitsDesc: A short string used for integer values to
- indicate the units in which the value is measured
- (e.g. "ms", "sec", "packets", etc). This attribute
- is optional.
-
- precision: For Counter objects, the value at which the
- Counter will roll-over. Required for all Counter
- objects.
-
- properties: A bitstring of boolean properties of the
- object. If the bit is on, it has the given property.
- This attribute is optional. The bits currently
- defined are:
-
- 0 -- If true, the difference between two values
- of this object is significant. For example,
- the changes in a packet count is always
- significant, it always conveys information.
- In this case, the 0 bit would be set. On the
- other hand, the difference between two readings
- of a queue length may be meaningless.
-
-
- IMPLEMENTATION SPECIFIC TYPES
-
- Each vendor or implementation specific value must be contained within
- an VendorSpecific object. The format of the VendorSpecific object is
- shown below.
-
- Type: VendorSpecific
-
- VendorSpecific ::= [APPLICATION 3] IMPLICIT SET of ANY
-
-
-
-
-
-
- Partridge & Trewitt [Page 7]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- For a detailed discussion of the need for this type, see RFC 1023.
-
- WELL-KNOWN TYPES
-
- There are some generally useful types which are defined across the
- system and are considered well-known. These types support abstract
- notions that are frequently used in other definitions.
-
- TYPE: Error
-
- Error ::= [APPLICATION 0] IMPLICIT SEQUENCE {
- errorCode INTEGER,
- errorOffset INTEGER
- errorDescription IA5String,
- }
-
- The Error type is returned within reply messages when an error is
- countered. The errorCode is a number specifying a general class of
- error. The errorOffset is the octet in the query where the error was
- discovered. Note that the query starts at the first octet (octet 0)
- of the HEMP data section. The errorDescription is a text message
- explaining the error. Note that the definition of this section is
- the same (except for the start of the offset) as that of the HEMP
- protocol error structure and the error codes have been selected to
- keep the code spaces distinct. This is intended to ease the
- processing of error messages. The defined errorCodes are:
-
- 100 -- Any error not listed below.
-
- 101 -- System error. The query processor has failed
- in some way.
-
- 102 -- Format error. An error has been detected in
- the input stream.
-
- 103 -- Stack error. A stack overflow or underflow has
- occurred.
-
- 104 -- Instruction error. The instruction is either
- unknown, or not supported on the object to which
- it has been applied.
-
- 105 -- Operand error. The wrong number of operands or
- inappropriate operands have been given to an
- instruction.
-
-
-
-
-
-
- Partridge & Trewitt [Page 8]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- TYPE: Counter
-
- Counter ::= [APPLICATION 4] IMPLICIT INTEGER
-
- The Counter type is an unsigned integer which is defined to roll-over
- to 0 when incremented past a certain value. (The roll-over point may
- be found by examining the attributes for the particular counter.)
- Counter sizes should be chosen such that the counters will not roll
- over more than once every 24 hours.
-
- TYPE: InstructionGroup
-
- InstructionGroup ::= [APPLICATION 5] IMPLICIT SEQUENCE
- of ANY
-
- An InstructionGroup is an encapsulated sequence of operands and
- operations. It allows applications to encode queries as objects.
-
- TYPE: Histogram
-
- Histogram ::= SET of HistEntry
-
- HistEntry ::= SEQUENCE {
- histValue INTEGER,
- histCount Counter
- }
-
- A Histogram associates a count, histCount, with a numeric value,
- histValue. No meaning is placed on the count or value by this
- definition. Each HistEntry may represent a simple map (e.g.,
- histCount instances of histValue), or a more complex relationship
- (e.g., a count of all values between this histValue and the next
- lowest histValue in the Histogram). The meaning of the particular
- Histogram is given in the object definition.
-
- TYPE: TrafficMatrix
-
- TrafficMatrix ::= SET of TrafficEntry
-
- TrafficEntry ::= SEQUENCE {
- src IpAddress,
- dst IpAddress,
- count Counter
- }
-
- A TrafficMatrix measures traffic observed between two IP addresses.
- Typically it is used to count packets flowing through a gateway.
-
-
-
-
- Partridge & Trewitt [Page 9]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- TYPE: IpAddress
-
- IpAddress ::= OCTETSTRING
-
- The 4 octet IP address. If the length of the string is less than 4
- then the missing octets are wildcarded. A zero length string is a
- default address (e.g., for indicating default routes).
-
-
- TYPE: Fraction
-
- Fraction ::= INTEGER
-
- A Fraction is an integer representation of a fractional value. It
- contains the numerator of a value as expressed over 256. (For
- example dividing the Fraction by 256 gives the fractional value.)
-
- TYPE: BootClock
-
- BootClock ::= INTEGER
-
- The time in milliseconds since the machine was last booted or reset.
- This value is always defined.
-
- TYPE: localClock
-
- LocalClock ::= INTEGER
-
- The local system clock, measured in milliseconds since 00:00 1
- January 1900 UTC. Assumed to be only a local estimate of the time.
- The value 0 is reserved for an uninitialized clock (For example, an
- uninitialized time-of-day chip.)
-
-
- TYPE: NetClock
-
- NetClock ::= INTEGER
-
- A network synchronized clock, which is assumed to be synchronized
- across some part of a network. The clock value is measured in
- milliseconds since 00:00 1 January 1900 UTC. Specific information
- about the synchronization protocol is found in the system variable
- dictionary. The value 0 is used to indicate an uninitialized clock.
-
- TYPE: TimeStamp
-
- TimeStamp ::= CHOICE {
- [0] BootClock
-
-
-
- Partridge & Trewitt [Page 10]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- [1] localClock
- [2] NetClock
- }
-
- A TimeStamp, which was taken from the boot clock, system clock or the
- synchronized clock. In general, a time of day is preferred to the
- time since boot, and a synchronized clock is preferred to an
- unsynchronized clock. It is more useful to know that an event
- occurred at a particular time, than that it happened so many
- milliseconds after the machine booted.
-
-
- OBJECT DEFINITIONS
-
- The Root Dictionary
-
- In HEMS, all data is stored in dictionaries, where a dictionary is
- thought to represent a conceptual grouping of values. The top-level
- dictionary is the root dictionary. The form of the root dictionary
- for is shown below.
-
- RootDictionary ::= [APPLICATION 32] IMPLICIT SET {
- SystemVariables,
- EventControls OPTIONAL,
- Interfaces,
- IpNetworkLayer,
- IpRoutingTable,
- IpTransportLayer,
- IpApplications OPTIONAL
- }
-
- The root dictionary is split into seven general dictionaries:
-
- - SystemVariables, which stores general system values such
- as the system clock, machine memory and system up/down
- status.
-
- - EventControls, which stores all objects necessary to
- observe and control the event generating mechanism in
- entities which support events.
-
- - interfaces, which contains all information on all
- the network interfaces and IP to physical address
- maps (ARP tables, X.25 Standard mappings, etc).
-
- - IpNetworkLayer, which contains information about the
- workings of the IP layer. This includes information such
- as routing tables, general packet counts, and host-traffic
-
-
-
- Partridge & Trewitt [Page 11]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- matrices.
-
- - IpRoutingTable, which contains information on how the
- machine routes packets. It proved more useful to segregate
- routing information than to keep it stored with the network
- layer data.
-
- - IpTransportLayer, which stores information on the transport
- protocols that the entity supports.
-
- - IpApplications, which may store information about various
- internet applications such as the domain system. This
- section is not required of HEMS entities.
-
- The next several sections define the values stored in the five
- dictionaries.
-
-
- The SystemVariables Dictionary
-
- The SystemVariables dictionary stores objects which are not strictly
- protocol, network, or application specific. Such objects include
- values such as the machine load, clocks and the processor status.
- The form of the dictionary is shown below.
-
- SystemVariables ::= [APPLICATION 33] IMPLICIT SET {
- referenceClock [0] IMPLICIT TimeStamp,
- netClockInfo [1] IMPLICIT SET OPTIONAL,
- processorLoad [2] IMPLICIT INTEGER,
- entityState [3] IMPLICIT INTEGER,
- kernelMemory [4] IMPLICIT OCTETSTRING OPTIONAL,
- pktBuffers [5] IMPLICIT INTEGER OPTIONAL,
- pktOctets [6] IMPLICIT INTEGER OPTIONAL,
- pktBuffersFree [7] IMPLICIT INTEGER OPTIONAL,
- pktOctetsFree [8] IMPLICIT INTEGER OPTIONAL
- systemID [9] IMPLICIT IA5STRING,
- }
-
- OBJECT: SystemVariables
-
- Type: SET
-
- Definition: see above
-
- The objects in the dictionary are defined below.
-
- OBJECT: referenceClock
-
-
-
-
- Partridge & Trewitt [Page 12]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Type: TimeStamp
-
- Definition: The system clock used for placing timestamps on
- information. Use of a NetClock is encouraged.
-
- Operations on Object: Defaults.
-
- Notes: Cross-network clock adjustment is best handled by a proper
- time synchronization protocol, not through the use of SET.
-
-
- OBJECT: netClockInfo
-
- Type: SET
-
- Definition: Detailed information on the referenceClock if the
- referenceClock is a NetClock. The format of this
- information is shown below.
-
- netClockInfo ::= [1] IMPLICIT SET {
- estError INTEGER,
- refClockType INTEGER {
- unspecified(0), primary-reference(1),
- ntp-secondary-reference(2), secondary-reference(3),
- wristwatch(4)
- }
- }
-
- The estError is the estimated error in milliseconds. The
- refClockType is a value indicating the type of reference
- clock consulted for network time (the values are taken
- directly from the Network Time Protocol specification,
- RFC-958).
-
- Object Status: Required if the referenceClock is a NetClock.
-
-
- OBJECT: processorLoad
-
- Type: Fraction
-
- Definition: A value, expressed as a Fraction, which indicates
- the current processing load on the entity. A value of
- 256 (= 1.0) is defined to be running at capacity. It
- is recognized that this is an imprecise definition since
- capacity can be measured in several ways. For example,
- a multiprocessor may still have plenty of capacity
- even if one processor is running at capacity,
-
-
-
- Partridge & Trewitt [Page 13]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- or it may be at capacity because that processor is the
- master processor and handles all context switching.
- The idea is for remote applications to be able to get some
- sense of the current workload on the entity. Also note
- that the time scale of the measurement should be small.
- A load measure that averages over the past 10 seconds
- is acceptable but a load measure that averages over the
- past 10 minutes is not. Implementors should chose some
- mapping between system load and this scale such that 256
- represents a machine under severe strain. (Note that this
- suggests that values greater than 256 may be returned in
- rare cases.)
-
- OBJECT: entityState
-
- Type: INTEGER
-
- Definition: An object which indicates the system state. There are
- several defined object values. Some values are read-only and
- can only be read from the object. Over values are write-only
- and will never be read from the object. Over values are
- write-only and will never be read from the object.The values
- are:
-
- The read-only values are:
-
- (0) -- reserved.
-
- (1) -- running. The entity is up and running.
-
- (2) -- testing. The entity is running some sort of
- diagnostics which may affect its network
- operation.
-
- The write-only values are:
-
- (0) -- reserved.
-
- (1) -- reset the entity.
-
- (2) -- reboot the entity. This value is assumed to
- cause a more aggressive recycling of the system
- than reset, though this need not be the case.
-
- (3) -- halt the entity. This value stops the
- entity. It assumed to prevent the entity from
- operating until it is manually restarted. (I.e.
- the halt takes the machine off the network).
-
-
-
- Partridge & Trewitt [Page 14]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Note: The ability to change an entity's state requires very strong
- access controls.
-
-
- Operations on Object: The defaults except as noted below.
-
- SET: Optionally writes the value into the object.
- The message requesting the SET must be authenticated.
-
- SET-MATCH: Optionally writes the value into the object
- if the current value is matched.
-
- OBJECT: kernelMemory
-
- Type: OCTETSTRING
-
- Definition: A sequence of octets which represents the image of the
- kernel software running on the entity. This facility is
- provided to allow remote network debugging.
-
- By kernel software, we mean that software which controls the
- operations and access to the hardware. In particular, the kernel
- is expected to contain all network software up through the IP
- layer.
-
- Implementations which use lightweight processes or segmented
- images should consider providing some way to map their internal
- representation into a single contiguous stream of octets.
-
- Note: Access control is required to read this object.
-
- Object Status: Useful.
-
- Operations on Object: The defaults except as noted below.
-
- GET-RANGE: Emits the section of memory specified.
-
- GET: Emits all of memory, but note that a GET on the system
- dictionary should *not* emit this object.
-
- OBJECT: pktBuffers
-
- Type: INTEGER
-
- Definition: The total number of packet buffers in the entity.
-
- Object Status: Required if the entity has a maximum number of
- buffers. Note that most entities do have a limit (even if it
-
-
-
- Partridge & Trewitt [Page 15]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- is for practical purposes, near infinite) and should return
- that limit.
-
- OBJECT: pktOctets
-
- Type: INTEGER
-
- Definition: The maximum number of octets that can be buffered in the
- entity at any one time.
-
- Object Status: Required if the entity has a maximum number of octets
- it can buffer. Note that most entities do have a limit and
- should return that limit.
-
-
- OBJECT: pktBuffersFree
-
- Type: INTEGER
-
- Definition: The number of packet buffers currently available.
- Subtracting pktBuffersFree from pktBuffers should give the
- number of buffers in use.
-
- Object Status: Required if there is a limit on the number of
- buffers.
-
-
- OBJECT: pktOctetsFree
-
- Type: INTEGER
-
- Definition: The number of octets currently available including those
- not used in allocated buffers. Subtracting this value from
- pktOctets should give the number of octets in use.
-
- This object can be used to track how well the entity buffers its
- data.
-
- Object Status: Required if there is a limit on the number of
- octets that can be buffered.
-
-
- OBJECT: systemID
-
- Type: IA5STRING
-
- Definition: The text identification of the entity. This value
- should include the full name of the vendor, the type of system,
-
-
-
- Partridge & Trewitt [Page 16]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- and the version number of the hardware and software running on
- the entity.
-
-
- The EventControls Dictionary
-
- The EventControls dictionary contains objects to control and
- monitor the delivery of event messages to operations centers.
- The format of this dictionary is shown below.
-
-
- EventControls ::= [APPLICATION 34] IMPLICIT SET OPTIONAL {
- lastEvent [0] IMPLICIT OCTETSTRING OPTIONAL,
- eventMessageID [1] IMPLICIT Counter,
- eventCenters [2] IMPLICIT SET of IpAddress,
- eventList [3] IMPLICIT SET of eventEntry,
- }
-
-
- OBJECT: eventControls
-
- Type: SET
-
- Definition: See above.
-
- Object Status: This object will be required in entities which
- support events, after the event definitions have been
- properly specified. See discussion of the event formats
- at the end of this memo.
-
- A description of the fields in this dictionary are given below.
-
-
- OBJECT: lastEvent
-
- Type: OCTETSTRING
-
- Definition: The last event message sent.
-
- Object Status: Implementation of this object is encouraged if the
- transport protocol used for events is unreliable (e.g., UDP).
-
-
- OBJECT: eventMessageID
-
-
- Type: Counter
-
-
-
-
- Partridge & Trewitt [Page 17]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The HEMP MessageId to be used in the next event
- message. Equals the number of events sent.
-
- OBJECT: eventCenters
-
- Type: SET of IpAddress
-
- Definition: The list of IP addresses to which events are sent.
- This list receives all events. For more selective event
- monitoring, centers should list themselves under the
- particular events of interest.
-
- Note: If the SET operator is defined then use of some form of
- access control is recommended.
-
- Operations on Object: The defaults except as listed below.
-
- CREATE: Adds an address to the list. The new address may
- not be a broadcast address (it may be a multicast
- address).
-
- DELETE: Deletes an address from the list.
-
- SET-MATCH: Defined on the IP address. Replaces the
- address with a new value.
-
- EMIT-MATCH: Defined on the IP address.
-
-
- OBJECT: eventList
-
- Type: SET of eventEntry
-
- Definition: An array of entries which contain objects which allow
- management centers to control how and when events are sent.
- (The contents of the eventEntry structure are explained below.)
-
- The eventControls Dictionary: eventList/eventEntry
-
- The eventEntry provides the necessary control objects to manage how
- a particular event is sent. The format of the eventEntry is shown
- below.
-
- eventEntry ::= [0] IMPLICIT SET {
- eventID [0] IMPLICIT INTEGER,
- eventMode [1] IMPLICIT INTEGER,
- eventCount [2] IMPLICIT Counter,
- threshold [3] IMPLICIT Counter,
-
-
-
- Partridge & Trewitt [Page 18]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- thresholdIncr [4] IMPLICIT INTEGER,
- eventExecution [5] IMPLICIT InstructionGroup OPTIONAL,
- eventCenters [6] IMPLICIT SET of IpAddress
- }
-
- OBJECT: eventEntry
-
- Type: SET
-
- Definition: See Above.
-
-
- OBJECT: eventID
-
- Type: INTEGER
-
- Definition: The particular event ID.
-
-
- OBJECT: eventMode
-
- Type: INTEGER
-
- Definition: A control object which determines how and whether this
- event is sent. The three modes are:
-
- 0 -- unused.
-
- 1 -- off. The event is not sent.
-
- 2 -- on. The event is sent every time it occurs.
-
- 3 -- threshold. The event is sent every time the
- event count reaches the threshold.
-
-
- OBJECT: eventCount
-
- Type: Counter
-
- Definition: The number of times this event has occurred.
-
-
- OBJECT: threshold
-
- Type: Counter
-
-
-
-
-
- Partridge & Trewitt [Page 19]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The event threshold. If the eventMode is "threshold"
- then a event is sent every time the eventCount equals this
- value.
-
- Operations on Object: The defaults except as noted below.
-
- SET: Changes the threshold.
-
- OBJECT: thresholdIncr
-
- Type: INTEGER
-
- Definition: The threshold increment. Every time a event threshold
- is reached, the threshold value is incremented by this value
- (modulo the precision of the Counter) to find the new
- threshold.
-
- Operations on Object: The defaults except as noted below.
-
- SET: Changes the increment.
-
-
- OBJECT: eventExecution
-
- Type: InstructionGroup
-
- Definition: A query to be executed whenever the event is actually
- sent. Any data retrieved by this query is appended to the
- event message.
-
- Object Status: Encouraged.
-
- Operations on Object: The defaults except as noted below.
-
- SET: Changes the buffer.
-
-
- OBJECT: eventCenters
-
- Type: SET
-
- Definition: The IP addresses of the monitoring centers which wish
- to listen to this particular event. Note that events should be
- sent to both these centers and the global list of event centers.
-
- Operations on Object: The defaults except as noted below.
-
- CREATE: Adds an address to the list of centers.
-
-
-
- Partridge & Trewitt [Page 20]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- DELETE: Deletes an address from the list.
-
- SET-MATCH: Defined on the IP address. Replaces the
- entry with a new value.
-
- EMIT-MATCH: Defined on the IP address.
-
-
- The Interfaces Dictionary
-
- The Interfaces dictionary a list of per-interface objects. Since
- one of the fundamental goals of HEMS is to use generic interfaces
- across differing hardwares, all hardware interfaces are described by
- the same data structure, the InterfaceData.
-
- Interfaces ::= [APPLICATION 35] IMPLICIT SET OF InterfaceData
-
- OBJECT: Interfaces
-
- Type: SET
-
- Definition: see above.
-
-
- The Interfaces Dictionary: The InterfaceData structure.
-
- The InterfaceData structure contains all information on a particular
- interface. The form of the structure is shown below.
-
- InterfaceData ::= [0] IMPLICIT SET {
- addresses [0] IMPLICIT SET of IpAddress,
- mtu [1] IMPLICIT INTEGER,
- netMask [2] IMPLICIT IpAddress,
- pktsIn [3] IMPLICIT Counter,
- pktsOut [4] IMPLICIT Counter,
- inputPktsDropped [5] IMPLICIT Counter,
- outputPktsDropped [6] IMPLICIT Counter,
- bcastPktsIn [7] IMPLICIT Counter OPTIONAL,
- bcastPktsOut [8] IMPLICIT Counter OPTIONAL,
- mcastPktsIn [9] IMPLICIT Counter OPTIONAL,
- mcastPktsOut [10] IMPLICIT Counter OPTIONAL,
- inputErrors [11] IMPLICIT Counter,
- outputErrors [12] IMPLICIT Counter,
- outputQLen [13] IMPLICIT INTEGER,
- name [14] IMPLICIT IA5String,
- status [15] IMPLICIT INTEGER,
- ifType [16] IMPLICIT INTEGER,
- mediaErrors [17] IMPLICIT Counter OPTIONAL,
-
-
-
- Partridge & Trewitt [Page 21]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- upTime [18] IMPLICIT TimeStamp,
- broadcast [19] IMPLICIT BITSTRING
- multicast [20] IMPLICIT SET of BITSTRING,
- addressList [21] IMPLICIT SET OPTIONAL,
- }
-
- OBJECT: InterfaceData
-
- Type: SET
-
- Definition: see above.
-
- Operations on Object: The defaults except as noted below.
-
- SET-MATCH: This operation is optionally defined on the
- address field of the structure. Only certain fields
- in this structure may be changed. The fields which
- may be SET are indicated in the descriptions below.
-
- GET-MATCH: Defined to emit information on the interface
- which matches the address given.
-
- The fields in the structure are defined below.
-
-
- OBJECT: addresses
-
- Type: SET of IpAddress
-
- Definition: The IP addresses that the interface accepts. Note that
- additional information on multicast addresses may be found in
- the IgmpValues dictionary.
-
-
- OBJECT: mtu
-
- Type: INTEGER
-
- Definition: The maximum transmission unit of the device.
-
-
- OBJECT: netMask
-
- Type: IpAddress
-
- Definition: The subnet mask, which is an address with all the
- network bits set to 1 and all the hosts bits set to 0. Used to
- identify subnets.
-
-
-
- Partridge & Trewitt [Page 22]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: pktsIn
-
- Type: Counter
-
- Definition: The total number of packets received on this interface
- including those in error.
-
-
- OBJECT: pktsOut
-
- Type: Counter
-
- Definition: The total number of packets that higher levels have
- attempted to send, including those that were not sent.
-
-
- OBJECT: inputPktsDropped
-
- Type: Counter
-
- Definition: The number of good inbound packets dropped (presumably
- to free up buffer space).
-
- OBJECT: outputPktsDropped
-
- Type: Counter
-
- Definition: The number of good outbound packets dropped (presumably
- to free up buffer space).
-
- OBJECT: bcastPktsIn
-
- Type: Counter
-
- Definition: The number of broadcast packets received including
- those in error.
-
- Object Status: Encouraged on interfaces that support broadcast.
-
-
- OBJECT: bcastPktsOut
-
- Type: Counter
-
- Definition: The number of broadcast packets that higher levels
- attempted to send, including those that were not sent.
-
- Object Status: Encouraged on interfaces that support broadcast.
-
-
-
- Partridge & Trewitt [Page 23]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: mcastPktsIn
-
- Type: Counter
-
- Definition: The number of multicast packets received including
- those in error.
-
- Object Status: Encouraged on interfaces that support multicast.
-
-
-
- OBJECT: mcastPktsOut
-
- Type: Counter
-
- Definition: The number of multicast packets sent, including those
- that were not sent.
-
- Object Status: Encouraged on interfaces that support multicast.
-
-
- OBJECT: inputErrors
-
- Type: Counter
-
- Definition: The number of inbound packets that could not be
- delivered. The number of inbound packets delivered
- should equal inputPkts less this value and inputPktsDropped.
-
- OBJECT: outputErrors
-
- Type: Counter
-
- Definition: The number of outbound packets that could not be
- transmitted because of errors. The number of outbound
- packets placed on the network should equal outputPkts
- less this value and outputPktsDropped.
-
- OBJECT: outputQLen
-
- Type: INTEGER
-
- Definition: The length of the output packet queue (in packets).
-
-
- OBJECT: name
-
- Type: IA5String
-
-
-
- Partridge & Trewitt [Page 24]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: A text string completely identifying the interface.
- This string should include the name of the manufacturer, the
- product name and the version of the hardware.
-
- OBJECT: status
-
- Type: INTEGER
-
- Definition: The status of the object. The status values are:
-
- 0 -- reserved
- 1 -- testing (the interface is in some test mode)
- 2 -- down (the interface is down)
- 3 -- up (the interface is up ready to pass packets)
-
- Note: If set operations are defined, access control is required.
-
- Operations on Object: The defaults except as noted below.
-
- SET: Optionally defined to change the state of the interface.
-
- OBJECT: ifType
-
- Type: INTEGER
-
- Definition: A flag which indicates the type of interface in use. The
- currently defined types are:
-
- 0 -- reserved
- 1 -- 1822 HDH
- 2 -- 1822
- 3 -- FDDI
- 4 -- DDN X.25
- 5 -- RFC-877 X.25
- 6 -- StarLan
- 7 -- Proteon 10Mbit
- 8 -- Proteon 80Mbit
- 9 -- Ethernet
- 10 -- 802.3 Ethernet
- 11 -- 802.4 Token Bus
- 12 -- 802.5 Token Ring
- 13 -- Point-to-Point Serial
-
- OBJECT: mediaErrors
-
- Type: Counter
-
-
-
-
-
- Partridge & Trewitt [Page 25]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: A counter of media errors, such as collisions on
- Ethernets, token regeneration on token passing rings, or lost
- RFNMs on PSNs.
-
- Object Status: Encouraged for interfaces to media which have such
- errors.
-
-
- OBJECT: upTime
-
- Type: TimeStamp
-
- Definition: When the interface was put in its current state.
-
-
- OBJECT: broadcast
-
- Type: BITSTRING
-
- Definition: Whether this interface has a physical broadcast
- address.
-
- Object Status: Required if the interface has a broadcast adddress.
-
-
- OBJECT: multicast
-
- Type: SET of BITSTRING
-
- Definition: The set of hardware multicast addresses currently
- enabled on the device.
-
- Object Status: Encouraged in interfaces which support multicast.
-
-
-
- OBJECT: addressList
-
- Definition: SET of addressMap
-
- addressMap ::= [0] IMPLICIT SET {
- ipAddr [0] IMPLICIT IpAddress
- physAddr [1] IMPLICIT BITSTRING
- }
-
- Definition: Most interfaces maintain tables mapping physical
- network address to IP address. An example is an ARP table.
- This table stores that map as a series of entries which map
-
-
-
- Partridge & Trewitt [Page 26]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- IP addresses to the physical address.
-
- Object Status: Required if the interface has to map IP addresses to
- physical addresses.
-
- The IpNetworkLayer Dictionary
-
- The IpNetworkLayer dictionary contains all information about the IP
- Layer. The format of the dictionary is shown below.
-
- IpNetworkLayer ::= [APPLICATION 36] IMPLICIT SET {
- gateway [0] IMPLICIT BOOLEAN,
- inputPkts [1] IMPLICIT Counter,
- inputErrors [2] IMPLICIT Counter,
- inputPktsDropped [3] IMPLICIT Counter,
- inputQLen [4] IMPLICIT INTEGER OPTIONAL,
- outputPkts [5] IMPLICIT Counter,
- outputErrors [6] IMPLICIT Counter,
- outputPktsDropped [7] IMPLICIT Counter,
- outputQLen [8] IMPLICIT INTEGER OPTIONAL,
- ipID [9] IMPLICIT Counter,
- fragCreated [10] IMPLICIT Counter OPTIONAL,
- fragRcvd [11] IMPLICIT Counter OPTIONAL,
- fragDropped [12] IMPLICIT Counter OPTIONAL,
- pktsReassembled [13] IMPLICIT Counter OPTIONAL,
- pktsFragmented [14] IMPLICIT Counter OPTIONAL,
- htm [15] IMPLICIT TrafficMatrix OPTIONAL,
- itm [16] IMPLICIT TrafficMatrix OPTIONAL
- }
-
- OBJECT: IpNetworkLayer
-
- Type: SET
-
- Definition: See above.
-
-
- The fields of the dictionary are defined below.
-
-
- OBJECT: gateway
-
- Type: BOOLEAN
-
- Definition: A boolean value which is true if the entity gateways
- packets.
-
-
-
-
-
- Partridge & Trewitt [Page 27]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: inputPkts
-
- Type: Counter
-
- Definition: The total number of input packets received including
- those in error.
-
-
- OBJECT: inputErrors
-
- Type: Counter
-
- Definition: The number of input packets discarded due to errors
- (unknown protocols, format errors, etc).
-
-
- OBJECT: inputPktsDropped
-
- Type: Counter
-
- Definition: The number of input packets dropped for lack of buffer
- space.
-
-
- OBJECT: inputQLen
-
- Type: INTEGER
-
- Definition: The number of inbound packets currently waiting to be
- processed by the IP layer.
-
- Object Status: Encouraged.
-
-
- OBJECT: outputPkts
-
- Type: Counter
-
- Definition: The total number of outbound packets including both
- those packets presented to the IP layer by higher layers and
- packets which are gatewayed.
-
-
- OBJECT: outputErrors
-
- Type: Counter
-
- Definition: The number of output packets discarded because of
-
-
-
- Partridge & Trewitt [Page 28]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- errors (unable to route, format errors, etc).
-
-
- OBJECT: outputPktsDropped
-
- Type: Counter
-
- Definition: The number of output packets dropped for lack of
- buffer space.
-
-
- OBJECT: outputQLen
-
- Type: INTEGER
-
- Definition: The number of outbound packets waiting to be processed
- by the IP layer.
-
- Object Status: Encouraged.
-
-
- OBJECT: ipID
-
- Type: Counter
-
- Definition: The next IP packet ID identifier to be used. Note
- that in some implementations the transport layer may set the
- IP identifier, in which case this value is used if the IP
- identifier has not been set by the transport layer.
-
- OBJECT: fragCreated
-
- Type: Counter
-
- Definition: The number of IP fragments created at this entity.
- (e.g., if an IP is split into three fragments at this entity,
- then this counter is incremented by three).
-
- Object Status: Encouraged.
-
-
- OBJECT: fragRcvd
-
- Type: Counter
-
- Definition: The number of IP fragments received at this entity.
-
- Object Status: Encouraged.
-
-
-
- Partridge & Trewitt [Page 29]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: fragDropped
-
- Type: Counter
-
- Definition: The number of IP fragments discarded at this entity
- for whatever reason (timed out, errors, etc).
-
- Object Status: Encouraged.
-
-
- OBJECT: pktsReassembled
-
- Type: Counter
-
- Definition: The number of IP datagrams that have been reassembled
- at this entity.
-
- Object Status: Encouraged
-
-
- OBJECT: pktsFragmented
-
- Type: Counter
-
- Definition: The number of IP datagrams that have been fragmented
- at this entity.
-
- Object Status: Encouraged.
-
-
- OBJECT: htm
-
- Type: TrafficMatrix
-
- Definition: A host traffic matrix, mapping all traffic switched any
- pair of sources and destinations. The count in each trafficEntry
- routeDst is expressed in packets. Source routed IP packets
- should be logged as being between their source and the
- destination (i.e., they should not be treated as destined for
- this entity).
-
- Notes: This information may be considered sensitive.
-
- Object Status: Encouraged in gateways.
-
-
-
- OBJECT: itm
-
-
-
- Partridge & Trewitt [Page 30]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Type: TrafficMatrix
-
- Definition: An interface traffic matrix showing traffic switched
- between interfaces in an entity. The source and destinations
- fields are the IP addresses of the interfaces between which
- the packet was switched. The count in each trafficEntry is
- expressed in packets.
-
- Object Status: Useful.
-
-
- The IpRoutingTable Dictionary
-
- The IpRoutingTable dictionary contains all routing information.
- Note that information about any routing protocols used to maintain
- the routing table is found under the entry for the routing protocol.
- The format of the routing dictionary is shown below.
-
- IpRoutingTable ::= [APPLICATION 37] IMPLICIT SET {
- routingProtocols [0] IMPLICIT OCTETSTRING,
- coreRouter [1] IMPLICIT BOOLEAN,
- autoSys [2] IMPLICIT INTEGER,
- metricUsed [3] IMPLICIT OCTET,
- [4] RoutingEntries,
- }
-
- OBJECT: IpRoutingTable
-
- Type: SET
-
- Definition: See above.
-
-
- The objects contained in the dictionary are described below.
-
- OBJECT: routingProtocols
-
- Type: OCTETSTRING
-
- Definition: A sparse list of the routing protocols used to update
- the routing table (e.g., EGP and ICMP). Each octet contains one
- of the following values:
-
- 0 -- anything not specified below.
-
- 1 -- local (non-protocol) information. (E.g.
- routing tables can be changed by hand).
-
-
-
-
- Partridge & Trewitt [Page 31]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- 2 -- HEMS (was changed/set by a HEMS operation)
-
- 3 -- Internet Control Message Protocols, (i.e.
- ICMP redirects).
-
- 4 -- Exterior Gateway Protocol (EGP).
-
- 5 -- Gateway-to-Gateway Protocol (GGP).
-
- 6 -- Dissimilar Gateway Protocol (DGP).
-
- 7 -- HELO
-
- 8 -- RIP
-
- 9 -- Proprietary IGP
-
- OBJECT: coreRouter
-
- Type: BOOLEAN
-
- Definition: This value is set to true if this entity is a reference
- router for any other router (i.e., if it distributes any of its
- routes to other machines).
-
-
- OBJECT: autoSys
-
- Type: INTEGER
-
- Definition: The autonomous system number of the autonomous system in
- which this entity resides.
-
-
- OBJECT: metricUsed
-
- Type: OCTET
-
- Definition: Classifies the routing metric used in the routing table
- entries. The value should be chosen from the list of values for
- routingProtocols above, and indicates the metric definition used
- (e.g., this entity uses an EGP metric internally).
-
-
- OBJECT: RoutingEntries
-
- Type: SET of RoutingEntry
-
-
-
-
- Partridge & Trewitt [Page 32]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The set of all routing entries. The RoutingEntry is
- defined below.
-
-
- The IpRoutingTable Dictionary: The RoutingEntry
-
- The RoutingEntry contains all information on a particular route.
- The format of the structure is shown below.
-
- RoutingEntry ::= [0] IMPLICIT SET {
- routeMetric [0] IMPLICIT INTEGER,
- routeDst [1] IMPLICIT IpAddress,
- nextHop [2] IMPLICIT IpAddress,
- routeAuthor [3] IMPLICIT IpAddress OPTIONAL,
- routeproto [4] IMPLICIT Octet OPTIONAL,
- routeTime [5] TimeStamp,
- routeTOS [6] IMPLICIT INTEGER OPTIONAL,
- valid [7] IMPLICIT BOOLEAN
- }
-
- OBJECT: RoutingEntry
-
- Type: SET
-
- Definition: See above.
-
- Operations on Object: Defaults except as specified below.
-
- CREATE: Adds a new routing entry. It should be confirmed
- that the entry is new.
-
- DELETE: Deletes a routing entry.
-
- GET-MATCH: The match operator is defined on the routeDst
- field. A match on an IpAddress is defined to be a
- search to find the route or routes which would be
- used to reach the IpAddress. More than one route
- may be applicable, in which case all possible routes
- should be returned.
-
- SET-MATCH: Is optionally defined on the object. A SET
- on an entire RoutingEntry replaces the entire entry
- with a new value. Certain fields (indicated below)
- can also be changed using a SET-MATCH.
-
- The match operator is defined on the routeDst and
- routeTOS fields. To SET a value, the match must be
- exact on the IP address (this is different from the
-
-
-
- Partridge & Trewitt [Page 33]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- search definition for GET-MATCH).
-
- Note that support of the operator on an entity
- which uses a dynamic routing protocol such as
- GGP or EGP will require close coordination with
- the routing protocol to ensure consistent data.
- (Arguably, this facility should not be supported
- on such machines).
-
- The definitions of the fields in the RoutingEntry are given below.
-
-
- OBJECT: routeMetric
-
- Type: INTEGER
-
- Definition: The routing metric on this route. Note that the type of
- metric is defined in the metricUsed field of the IpRoutingTable
- dictionary.
-
- OBJECT: routeDst
-
- Type: IpAddress
-
- Definition: The final destination that can be reached via this
- route.
-
-
- OBJECT: nextHop
-
- Type: IpAddress
-
- Definition: The next hop to the final destination.
-
-
- OBJECT: routeAuthor
-
- Type: IpAddress
-
- Definition: The IP address of the entity from which this route was
- *first* received. That is, the first entity which stated that
- was reached via nextHop. The default IpAddress should be used
- to indicate routes which originated on the entity.
-
- Object Status: Encouraged.
-
-
- OBJECT: routeProto
-
-
-
- Partridge & Trewitt [Page 34]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Type: Octet
-
- Definition: The routing protocol from which this route was learned.
- The value is taken from the list of values for routingProtocols
- above.
-
- Object Status: Encouraged.
-
-
- OBJECT: routeTime
-
- Type: TimeStamp
-
- Definition: When this route was first received.
-
- Object Status: Encouraged.
-
-
- OBJECT: routeTOS
-
- Type: INTEGER
-
- Definition: The IP Type of Service which this routing entry serves.
-
- Object Status: Required if type of service routing is supported.
-
-
- OBJECT: valid
-
- Type: BOOLEAN
-
- Definition: Whether the route is active. (Some machines retain
- routes which are no longer valid for various reasons.)
-
- The IpTransportLayer Dictionary
-
- The IpTransportLayer Dictionary contains any information which
- pertains to transport protocols which use the IP protocol as the
- network protocol. For ease of reference, the ASN.1 tag of each
- transport protocol's dictionary is the same as the assigned IP
- Protocol number. The definition of the IpTransportLayer
- dictionary is shown below. Note that dictionaries for many
- protocols are not yet defined.
-
- IpTransportLayer ::= [APPLICATION 38] IMPLICIT SET {
- [0] IMPLICIT ProtocolsSupported,
- [1] IMPLICIT IcmpValues,
- [2] IMPLICIT IgmpValues OPTIONAL,
-
-
-
- Partridge & Trewitt [Page 35]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- [3] IMPLICIT GgpValues OPTIONAL,
- [7] IMPLICIT TcpValues OPTIONAL,
- [8] IMPLICIT EgpValues OPTIONAL,
- [17] IMPLICIT UdpValues OPTIONAL,
- [20] IMPLICIT HmpValues OPTIONAL,
- [27] IMPLICIT RdpValues OPTIONAL,
- [30] IMPLICIT NetbltValues OPTIONAL,
- }
-
- OBJECT: IpTransportLayer
-
- Type: SET
-
- Definition: see above.
-
- The objects in the dictionary are defined below.
-
- The IpTransportLayer Dictionary: ProtocolsSupported
-
- OBJECT: protocolsSupported
-
- Type: OCTETSTRING
-
- Definition: Sparse list of transport protocols supported. Each
- octet in the OCTETSTRING contains the IP protocol number of a
- supported protocol. For the purposes of this definition, an
- entity supports a protocol if it both contains software to
- makes it possible for the protocol to be used in
- communications with the entity, AND the entity keeps the
- required values (if any) defined in this memo for that protocol.
-
-
- The IpTransportLayer Dictionary: IcmpValues
-
- The IcmpValues dictionary is a subdictionary of the IpTransportLayer
- dictionary which tracks the workings of the Internet Control Message
- Protocol, defined in RFC-792. The form of the dictionary is shown
- below.
- IcmpValues ::= SET {
- inputPktCount [0] IMPLICIT Counter,
- inputPktErrors [1] IMPLICIT Counter,
- inputPktDeliver [2] IMPLICIT Counter,
- inputPktTypes [3] IMPLICIT Histogram OPTIONAL,
- outputPktCount [4] IMPLICIT Counter,
- outputPktErrors [5] IMPLICIT Counter,
- outputPktTypes [6] IMPLICIT Histogram OPTIONAL,
- icmpTraffic [7] IMPLICIT TrafficMatrix OPTIONAL,
- ipID [8] IMPLICIT Counter OPTIONAL
-
-
-
- Partridge & Trewitt [Page 36]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- }
-
- OBJECT: IcmpValues
-
- Type: SET
-
- Definition: see above.
-
- The objects in the dictionary are defined below.
-
-
- OBJECT: inputPktCount
-
- Type: Counter
-
- Definition: The total number of ICMP packets received (including
- those in error).
-
-
-
- OBJECT: inputPktErrors
-
- Type: Counter
-
- Definition: The number of ICMP packets received which proved to
- have errors (bad checksums, bad length etc). Subtracting this
- value from the inputPktCount field should give the number of
- valid ICMP packets received.
-
-
- OBJECT: inputPktDeliver
-
- Type: Counter
-
- Definition: The number of valid ICMP packets which were
- successfully processed (e.g., delivered to the higher
- protocol).
-
-
- OBJECT: inputPktTypes
-
- Type: Histogram
-
- Definition: A histogram of ICMP messages types and codes received,
- not including those messages that proved to contain errors.
- The histogram histValue field contains a 16-bit value which is
- the the (ICMP type * 256) + ICMP code, and the histCount field
- contains the number of valid messages containing this
-
-
-
- Partridge & Trewitt [Page 37]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- type/code pair which have been received.
-
- The message type and code values are those defined in RFC-792
- (e.g., the Time Exceeded Message with a code of "fragment
- reassembly time exceeded" is (11 * 256) + 1 = 2817).
-
- Object Status: Useful.
-
- Operations on Object: The defaults except as listed below:
-
- GET-MATCH: Match is defined on the value of the histValue
- field.
-
- OBJECT: outputPktCount
-
- Type: Counter
-
- Definition: The total number of ICMP packets that the entity
- attempted to send (including those that failed due to lack of
- buffers, a missing route or other transient transmission
- problems).
-
-
- OBJECT: outputPktErrors
-
- Type: Counter
-
- Definition: The number of ICMP packets which the entity could not
- send due to transmission problems such as the lack of buffers, a
- missing route or other transient transmission problems. This
- value is not required to include errors which the ICMP layer
- could not reasonably be expected to detect such as damage to the
- packet in transit. Subtracting this value from the PktCount
- field should give the number of ICMP packets the entity believes
- it successfully sent.
-
-
-
- OBJECT: outputPktTypes
-
- Type: Histogram
-
- Definition: A histogram of ICMP messages types and codes sent,
- including those messages that later failed to be transmitted.
- The histogram histValue field contains a 16-bit value which is
- the the (ICMP type * 256) + ICMP code, and the histCount field
- contains the number of valid messages containing this type/code
- pair which have been sent.
-
-
-
- Partridge & Trewitt [Page 38]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The message type and code values are those defined in RFC-792
- (e.g., the Time Exceeded Message with a code of "fragment
- reassembly time exceeded" is (11 * 256) + 1 = 2817).
-
-
- Object Status: Useful.
-
- Operations on Object: The defaults except as listed below:
-
- GET-MATCH: Match is defined on the value of the histValue
- field.
-
- OBJECT: icmpTraffic
-
- Type: TrafficMatrix
-
- Definition: All ICMP traffic which has originated on this machine.
- The source address in the traffic matrix should be the interface
- from which the packet was sent. The destination is the address
- to which the packet is to finally be delivered (not an
- intermediate hop).
-
- Object Status: Useful.
-
-
- OBJECT: ipID
-
- Type: Counter
-
- Definition: The next IP packet ID identifier to be used by the ICMP
- code.
-
- Object Status: Required if the ICMP code generates its own IP
- identifiers.
-
-
-
- The IpTransportLayer Dictionary: IgmpValues
-
- IgmpValues ::= SET {
- conformance [0] IMPLICIT INTEGER,
- inputPktCount [1] IMPLICIT Counter,
- inputPktErrors [2] IMPLICIT Counter,
- inputPktTypes [3] IMPLICIT Histogram OPTIONAL,
- outputPktCount [4] IMPLICIT Counter,
- outputPktErrors [5] IMPLICIT Counter,
- outputPktTypes [6] IMPLICIT Histogram OPTIONAL,
- igmpTraffic [7] IMPLICIT TrafficMatrix OPTIONAL
-
-
-
- Partridge & Trewitt [Page 39]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- igmpGroups [8] IMPLICIT SET of IgmpGroupEntry,
- ipID [9] IMPLICIT Counter OPTIONAL,
- }
-
- OBJECT: IgmpValues
-
- Type: SET
-
- Definition: The dictionary of information on the Internet Group
- Management Protocol (RFC-988).
-
- Object Status: Required in hosts which support IGMP.
-
- The objects stored in this dictionary are defined below.
-
-
- OBJECT: conformance
-
- Type: INTEGER
-
- Definition: The level of conformance with RFC-988. The conformance
- levels are:
-
- 0 -- Level 0. No support for IP multicasting
-
- 1 -- Level 1. Support for sending but not receiving
- multicast datagrams.
-
- 2 -- Level 2. Full support for IP multicasting.
-
- These values are taken directly from RFC-988.
-
-
- OBJECT: inputPktCount
-
- Type: Counter
-
- Definition: The number of IGMP packets received including those
- that proved to be in error.
-
- OBJECT: inputPktErrors
-
- Type: Counter
-
- Definition: The number of IGMP packets received which proved to
- be in error. This value subtracted from inputPktCount should
- give the number of valid IGMP packets received.
-
-
-
-
- Partridge & Trewitt [Page 40]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: inputPktTypes
-
- Type: Histogram
-
- Definition: A histogram of IGMP messages types and codes sent,
- including those messages that later failed to be transmitted.
- The histogram histValue field contains a 16-bit value which
- is the the (IGMP type * 256) + IGMP code, and the histCount
- field contains the number of valid messages containing this
- type/code pair which have been sent.
-
- The type and code values are taken from RFC-988.
-
-
- OBJECT: outputPktCount
-
- Type: Counter
-
- Definition: The total number of IGMP packets that the entity
- attempted to send (including those that failed due to lack
- of buffers, a missing route or other transient transmission
- problems).
-
- OBJECT: outputPktErrors
-
- Type: Counter
-
- Definition: The number of IGMP packets which the entity could not
- send due to transmission problems such as the lack of buffers,
- a missing route or other transient transmission problems.
- This value is not required to include errors which the IGMP
- layer could not reasonably be expected to detect such as damage
- to the packet in transit. Subtracting this value from the
- outputPktCount field should give the number of IGMP packets
- the entity believes it successfully sent.
-
- OBJECT: outputPktTypes
-
- Type: Histogram
-
- Definition: A histogram of IGMP messages types and codes sent,
- including those messages that later failed to be transmitted.
- The histogram histValue field contains a 16-bit value which is
- the the (IGMP type * 256) + IGMP code, and the histCount field
- contains the number of valid messages containing this type/code
- pair which have been sent.
-
- The type and code values are taken from RFC-988.
-
-
-
- Partridge & Trewitt [Page 41]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: igmpTraffic
-
- Type: TrafficMatrix
-
- Definition: All IGMP traffic which has originated on this machine.
- The source address in the traffic matrix should be the interface
- from which the packet was sent. The destination is the address
- to which the packet is to finally be delivered (not an
- intermediate hop).
-
- Object Status: Useful.
-
-
-
- OBJECT: igmpGroups
-
- Type: SET
-
- Definition: The various igmpGroups of which this host is aware.
- This is stored as a set of IgmpGroupEntry. The format of an
- IgmpGroupEntry is shown below.
-
- IgmpGroupEntry ::= [0] SET {
- groupAddress [0] IMPLICIT IpAddress,
- groupAccessKey [1] IMPLICIT OCTETSTRING,
- groupAgent [2] IMPLICIT BOOLEAN,
- }
-
- The groupAddress is the multicast IP address. The
- groupAccessKey is the 8 octet key -- this key may be
- confidential and should only be available to authorized querying
- entities. The groupAgent field is true if this entity is an
- agent for the multicast group.
-
- OBJECT: ipID
-
- Type: Counter
-
- Definition: The next IP packet ID identifier to be used by the IGMP
- code.
-
- Object Status: Required if the IGMP code generates its own IP
- identifiers.
-
-
-
-
-
-
-
-
- Partridge & Trewitt [Page 42]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The IpTransportLayer Dictionary: GgpValues
-
- The definition of the GgpValues dictionary is left for further
- study.
-
- The IpTransportLayer Dictionary: TcpValues
-
- The TcpValues dictionary is a subdictionary of the IpTransportLayer
- dictionary which tracks the workings of the Transmission Control
- Protocol, defined in RFC-793. The definitions of several objects in
- this dictionary refer to definitions in RFC-793. The form of the
- dictionary is shown below.
-
-
- TcpValues ::= SET {
- [0] IMPLICIT TcpParam
- [1] IMPLICIT TcpStats OPTIONAL,
- tcpConnData [2] IMPLICIT SET of TcpConn,
- }
-
- OBJECT: TcpValues
-
- Type: IMPLICIT SET
-
- Definition: see above.
-
- Object Status: Required if the entity supports TCP.
-
- The objects in the dictionary are defined in the next few sections.
-
-
- The IpTransportLayer Dictionary: TcpValues/TcpParam
-
- The TcpParam dictionary contains information about certain
- parameters such as round-trip timer estimation constants which are
- managed on a per-machine basis. The form of the dictionary is shown
- below.
-
- TcpParam ::= SET {
- tcpRtoA [0] IMPLICIT IA5String,
- tcpRtoParam [1] IMPLICIT SET of RtoParam,
- ipID [2] IMPLICIT Counter,
- tcpRtoMin [3] IMPLICIT INTEGER OPTIONAL,
- tcpRtoMax [4] IMPLICIT INTEGER OPTIONAL,
- tcpMaxSegSiz [5] IMPLICIT INTEGER,
- tcpMaxConn [6] IMPLICIT INTEGER OPTIONAL,
- tcpMaxWindow [7] IMPLICIT INTEGER OPTIONAL,
- }
-
-
-
- Partridge & Trewitt [Page 43]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: tcpParam
-
- Type: SET
-
- Definition: see above.
-
-
- The definition of the objects in the tcpParam dictionary are given
- below.
-
- OBJECT: tcpRtoA
-
- Type: IA5String
-
- Definition: The TCP retransmission timeout algorithm used. The
- algorithm is expressed as one or more equations to generate
- a target value, "RTO[N]", which is the retransmission timeout
- for packet "N". Expressions should use well understood
- symbols such as * for multiplication and / for division, and
- parentheses to indicate precedence. Variables should begin
- with an upper case character. Multiple equations should be
- separated by semi-colons. Comments should be in braces (i.e.,
- {}). Constants should begin with a lower case character. In
- addition to "RTO[N]" the symbol "S[N]" is defined to mean the
- round-trip sample for packet N. Using this syntax, the
- algorithm in RFC-793 would be expressed as:
-
- RTO[N] = SRTT[N] * beta ;
- SRTT[N] = ( S[N-1] * alpha) + (SRTT[N-1] * (1 - alpha))
-
- Note: The syntax probably needs to be refined so that it can be
- parsed and interpreted by a program. This is left for future
- study.
-
-
- OBJECT: tcpRtoParam
-
- Type: SET of RtoParam
-
- Definition: The list of the values of the constants used by the
- retransmission timeout algorithm. The format of the RtoParam
- structure is shown below.
-
- RtoParam ::= SEQUENCE {
- name IA5String,
- value Fraction
- }
-
-
-
-
- Partridge & Trewitt [Page 44]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The name is the name of the constant as expressed in the
- tcpRtoA (e.g., "beta").
-
- OBJECT: ipID
-
- Type: Counter
-
- Definition: The next IP packet ID identifier to be used by the TCP
- code.
-
- Object Status: Required if the TCP code generates its own IP
- identifiers.
-
- OBJECT: tcpRtoMin
-
- Type: INTEGER
-
- Definition: The minimum value the TCP implementation permits for
- the retransmission timeout (RTO), measured in milliseconds.
-
- Note: If the SET operation is optionally defined, access control
- must be exercised.
-
- Object Status: Required if the implementation uses the suggested
- algorithm in RFC-793 or if the implementation sets any limits
- on the minimum RTO.
-
- Operations on Object: The defaults except as listed below:
-
- SET: Optionally defined to change the value. Implementations
- should confirm that the new value is less than tcpRtoMax.
-
-
- OBJECT: tcpRtoMax
-
- Type: INTEGER
-
- Definition: The maximum value the TCP implementation permits for
- the retransmission timeout (RTO), measured in milliseconds.
-
- Note: If the SET operation is optionally defined, access control
- must be exercised.
-
- Object Status: Required if the implementation uses the suggested
- algorithm in RFC-793 or if the implementation sets any limits
- on the maximum RTO.
-
- Operations on Object: The defaults except as listed below:
-
-
-
- Partridge & Trewitt [Page 45]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- SET: Optionally defined to change the value. Implementations
- should confirm that the new value is greater than tcpRtoMax,
- and that the value is large (i.e., several seconds).
-
-
- OBJECT: tcpMaxSegSiz
-
- Type: INTEGER
-
- Definition: The maximum segment size used by this implementation.
-
- Object Status: Required if the entity sets an upper limit on the
- MTU. (Some implementations have no constraints, but chose an
- MTU from external constraints such as the maximum MTU of the
- network interface in use.)
-
-
- OBJECT: tcpMaxConn
-
- Type: INTEGER
-
- Definition: An optional value, which must be present if the entity
- has a limit on the total number of TCP connections it can support.
-
- Object Status: Required if the entity sets limits.
-
- Note: If the SET operation is defined, access control must be
- exercised.
-
- Operations on Object: The defaults except as listed below:
-
- SET: Optionally defined to change the value. If the
- new value is less than the number of currently
- open connections, implementations are *not* required
- to close existing connections, but may not open
- any additional ones.
-
-
- OBJECT: tcpMaxWindow
-
- Type: INTEGER
-
- Definition: An optional value, which must be present if the entity
- places a fixed upper limit on the size of any connection's TCP
- window (i.e., if the maximum window size is not per connection
- configurable).
-
- Object Status: Required if the entity sets limits.
-
-
-
- Partridge & Trewitt [Page 46]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Note: If the SET operation is defined, access control must be
- exercised.
-
- Operations on Object: The defaults except as listed below:
-
- SET: Optionally defined to change the value. The new
- value must be at least the size of one maximum
- TCP segment.
-
- The IpTransportLayer Dictionary: TcpValues/TcpStats
-
- The TcpStats dictionary stores general information about the
- workings of the TCP layer. The form of the dictionary is shown
- below.
-
- TcpStats ::= SET {
- connAttempts [0] IMPLICIT Counter OPTIONAL,
- connOpened [1] IMPLICIT Counter OPTIONAL,
- connAccepted [2] IMPLICIT Counter OPTIONAL,
- connClosed [3] IMPLICIT Counter OPTIONAL,
- connAborted [4] IMPLICIT Counter OPTIONAL,
- connAbortedInfo [5] IMPLICIT Histogram OPTIONAL,
- octetsIn [6] IMPLICIT Counter OPTIONAL,
- octetsOut [7] IMPLICIT Counter OPTIONAL,
- octetsInDup [8] IMPLICIT Counter OPTIONAL,
- octetsRetrans [9] IMPLICIT Counter OPTIONAL,
- inputPkts [10] IMPLICIT Counter OPTIONAL,
- retransPkts [11] IMPLICIT Counter OPTIONAL,
- outputPkts [12] IMPLICIT Counter OPTIONAL,
- dupPkts [13] IMPLICIT Counter OPTIONAL,
-
- }
-
- OBJECT: TcpStats
-
- Type: SET
-
- Definition: See above.
-
- Object Status: Encouraged.
-
- The definition of the fields in the dictionary are given below.
-
-
- OBJECT: connAttempts
-
- Type: Counter
-
-
-
-
- Partridge & Trewitt [Page 47]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The number of connection attempts that have been made
- from this host. This includes pending attempts.
-
- Object Status: Encouraged.
-
-
- OBJECT: connOpened
-
- Type: Counter
-
- Definition: The number of connection attempts from this host which
- successfully generated an open connection. This includes
- currently open connections.
-
- Object Status: Encouraged.
-
-
- OBJECT: connAccepted
-
- Type: Counter
-
- Definition: The number of connections accepted by listening peers
- on this entity. This includes currently open connections.
-
- Object Status: Encouraged.
-
-
- OBJECT: connClosed
-
- Type: Counter
-
- Definition: The number of connections which were properly closed.
-
- Object Status: Encouraged.
-
-
- OBJECT: connAborted
-
- Type: Counter
-
- Definition: The number of connections which were aborted. Note
- that if implementations trace how the connection was aborted,
- they are encouraged to use the connAbortedInfo histogram.
-
- Object Status: Encouraged.
-
-
- OBJECT: connAbortedInfo
-
-
-
- Partridge & Trewitt [Page 48]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Type: Histogram
-
- Definition: The number of connections which were aborted by type of
- abort. The histValue is one of the codes listed below. The
- histCount is the number of connections aborted for this reason.
- The histValues codes are:
-
- 0 -- an abort condition not specified below
- 1 -- remote abort
- 2 -- local application abort
- 3 -- local protocol level abort
-
- Object Status: Useful
-
-
- OBJECT: octetsIn
-
- Type: Counter
-
- Definition: The total number of TCP octets (not including
- duplicates) received at this entity.
-
- Object Status: Required if TcpStats is implemented.
-
-
- OBJECT: octetsOut
-
- Type: Counter
-
- Definition: The total number of TCP octets (not including
- retransmissions) sent from this entity.
-
- Object Status: Required if TcpStats is implemented.
-
-
- OBJECT: octetsInDup
-
- Type: Counter
-
- Definition: The total number of TCP octets received which were
- duplicates.
-
- Object Status: Required if TcpStats is implemented.
-
-
- OBJECT: octetsReTrans
-
- Type: Counter
-
-
-
- Partridge & Trewitt [Page 49]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The total number of TCP octets which have been
- retransmitted.
-
- Object Status: Required if TcpStats is implemented.
-
-
- OBJECT: inputPkts
-
- Type: Counter
-
- Definition: The total number of valid packets received, including
- those on current connections.
-
- Object Status: Useful.
-
-
- OBJECT: retransPkts
-
- Type: Counter
-
- Definition: The total number of packets retransmitted.
-
- Object Status: Useful.
-
-
- OBJECT: outputPkts
-
- Type: Counter
-
- Definition: The total number of packets sent.
-
- Object Status: Useful.
-
-
- OBJECT: dupPkts
-
- Type: Counter
-
- Definition: The number of packets received which contained only
- data already received.
-
- Object Status: Useful.
-
-
-
-
-
-
-
-
-
- Partridge & Trewitt [Page 50]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The IpTransportLayer Dictionary: TcpValues/TcpConn
-
- The tcpConnData field in the TcpValues dictionary is a set of
- TcpConn, where each TcpConn contains information on a particular TCP
- connection. The definition of TcpConn is shown below.
-
- TcpConn ::= SET {
- localPort [0] IMPLICIT INTEGER,
- localAddress [1] IMPLICIT IpAddress,
- foreignPort [2] IMPLICIT INTEGER,
- foreignAddress [3] IMPLICIT IpAddress,
- state [4] IMPLICIT INTEGER,
- snduna [5] IMPLICIT INTEGER,
- sndnxt [6] IMPLICIT INTEGER,
- sndwnd [7] IMPLICIT INTEGER,
- congwnd [8] IMPLICIT INTEGER,
- rcvnxt [9] IMPLICIT INTEGER,
- rcvwnd [10] IMPLICIT INTEGER,
- srtt [11] IMPLICIT INTEGER OPTIONAL,
- lastrtt [12] IMPLICIT INTEGER OPTIONAL,
- maxSegSize [13] IMPLICIT INTEGER,
- octetsSent [14] IMPLICIT Counter OPTIONAL,
- octetsRXmit [15] IMPLICIT Counter OPTIONAL,
- octetsRcvd [16] IMPLICIT Counter OPTIONAL,
- octetDups [17] IMPLICIT Counter OPTIONAL,
- octetPastWin [18] IMPLICIT Counter OPTIONAL,
- segSizes [19] IMPLICIT Histogram OPTIONAL,
- }
-
- The set of TCP connections can be searched in a number of ways based
- on the local and foreign addresses (including the port number).
- Individual values of a connection cannot be retrieved without a
- search.
-
- OBJECT: TcpConn
-
- Type: SET
-
- Definition: The per TCP connection data.
-
- Operations on Object: The defaults except as listed below:
-
- GET-MATCH: Defined on any combination of values of
- localAddress, localPort, foreignAddress and
- foreignPort. Returns all connections which match
- the template. (For example, GET-MATCH on a
- particular foreignAddress returns all connections
- to that address.)
-
-
-
- Partridge & Trewitt [Page 51]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The definitions of the fields of the tcpConn structure are given
- below.
-
- OBJECT: localPort
-
- Type: INTEGER
-
- Definition: The local port number of this connection.
-
- Operations on Object: Defaults. Note that MATCH operators may be
- applied to this object to locate information on a particular TCP
- connection.
-
-
- OBJECT: localAddress
-
- Type: IpAddress
-
- Definition: The local IP address of this connection. May be the
- default IP address defined above. This value may not be valid
- in certain states.
-
- Operations on Object: Defaults. Note that MATCH operators may be
- applied to this object to locate information on a particular
- TCP connection.
-
- OBJECT: foreignPort
-
- Type: INTEGER
-
- Definition: The foreign port number of this connection. This value
- may be meaningless if the local peer is in certain states (e.g.,
- LISTEN).
-
- Operations on Object: Defaults. Note that MATCH operators may be
- applied to this object to locate information on a particular TCP
- connection.
-
-
- OBJECT: foreignAddress
-
- Type: IpAddress
-
- Definition: The foreign IP address of this connection. This value
- may be meaningless if the local peer is in certain states (e.g.,
- LISTEN).
-
- Operations on Object: Defaults. Note that MATCH operators may be
-
-
-
- Partridge & Trewitt [Page 52]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- applied to this object to locate information on a particular
- TCP connection.
-
- OBJECT: state
-
- Type: INTEGER
-
- Definition: The current state of the local peer. The values
- corresponding to the different states are: close(0), listen(1),
- syn-sent(2), syn-received(3), established(4), close-wait(5),
- fin-wait-1(6), closing(7), last-ack(8), fin-wait-2(9),
- time-wait(10). Implementations must map internal
- representations of the state into these values.
-
-
- OBJECT: snduna
-
- Type: INTEGER
-
- Definition: The SND.UNA value as defined in RFC-793.
-
-
- OBJECT: sndnxt
-
- Type: INTEGER
-
- Definition: The SND.NXT value as defined in RFC-793.
-
-
- OBJECT: sndwnd
-
- Type: INTEGER
-
- Definition: The SND.WND value as defined in RFC-793.
-
-
- OBJECT: congwnd
-
- Type: INTEGER
-
- Definition: The congestion window. This value is less than or
- equal to sndwnd. If less than sndwnd, then congestion
- control is in effect and congwnd is the reduced send window
- size in use.
-
- OBJECT: rcvnxt
-
- Type: INTEGER
-
-
-
- Partridge & Trewitt [Page 53]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The RCV.NXT value as defined in RFC-793.
-
-
- OBJECT: rcvwnd
-
- Type: INTEGER
-
- Definition: The RCV.WND value as defined in RFC-793.
-
-
- OBJECT: srtt
-
- Type: INTEGER
-
- Definition: The smoothed round-trip time in milliseconds.
-
- Object Status: Required if the implementation maintains a smoothed
- round-trip time.
-
-
- OBJECT: lastrtt
-
- Type: INTEGER
-
- Definition: The last round-trip time sample taken in milliseconds.
-
- Object Status: Encouraged.
-
-
- OBJECT: maxSegSize
-
- Type: INTEGER
-
- Definition: The maximum segment size that can be used on this
- connection.
-
-
- OBJECT: octetsSent
-
- Type: Counter
-
- Definition: The total number of octets transmitted since the
- connection was opened, not including retransmissions. Can
- alternatively be thought of as the current length of the
- stream.
-
- Object Status: Encouraged.
-
-
-
-
- Partridge & Trewitt [Page 54]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: octetsRXmit
-
- Type: Counter
-
- Definition: The total number of octets retransmitted since the
- connection was opened. This plus octetsSent should give the
- total number of octets sent.
-
- Object Status: Encouraged.
-
-
- OBJECT: octetsRcvd
-
- Type: Counter
-
- Definition: The number of octets received since the connection was
- opened, not including duplicates received. The receiver's
- version of octetsSent.
-
- Object Status: Encouraged.
-
-
- OBJECT: octetDups
-
- Type: Counter
-
- Definition: The total number of octets received since the
- connection was opened which were redundant (i.e., they had been
- previously received).
-
- Object Status: Encouraged.
-
-
- OBJECT: octetPastWin
-
- Type: Counter
-
- Definition: The number of segments which contained data beyond
- the upper edge of the receive window.
-
- Object Status: Encouraged
-
-
- OBJECT: segSizes
-
- Type: Histogram
-
- Definition: A histogram of the sizes of the packets sent on the
-
-
-
- Partridge & Trewitt [Page 55]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- connection (useful for catching cases of silly-window syndrome).
- This histogram is an range histogram, measuring the number of
- segments whose size fell into a give range. The histogram
- histValue field contains a segment size, and the histCount
- field contains the number of segments between this size and
- the next largest size.
-
- Object Status: Useful.
-
- The IpTransportLayer Dictionary: EgpValues
-
- The EgpValues dictionary stores information about the workings of
- the Exterior Gateway Protocol, defined in RFC-904. The format of
- the dictionary is shown below.
-
- EgpValues ::= SET {
- egpState [0] IMPLICIT INTEGER,
- [1] IMPLICIT EgpParam,
- [2] IMPLICIT EgpStats OPTIONAL,
- egpPeerData [3] IMPLICIT SET of EgpPeer
- }
-
-
- OBJECT: EgpValues
-
- Type: SET
-
- Definition: See above.
-
- Object Status: Required in entities which support EGP.
-
- The definitions of the subdictionaries of this dictionary are given
- below.
-
-
- OBJECT: egpState
-
- Type: INTEGER
-
- Definition: The state of the EGP system. The state values are:
-
- 0 -- Idle
- 1 -- Acquisition
- 2 -- Down
- 3 -- Up
- 4 -- Cease
-
- These values are taken directly from RFC-904.
-
-
-
- Partridge & Trewitt [Page 56]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The IpTransportLayer Dictionary: EgpValues/EgpParam
-
- The EgpParam dictionary stores the various EGP parameters. The
- format of the dictionary is shown below.
-
- EgpParam ::= SET {
- p1 [0] IMPLICIT INTEGER,
- p2 [1] IMPLICIT INTEGER,
- p3 [2] IMPLICIT INTEGER,
- p4 [3] IMPLICIT INTEGER,
- p5 [4] IMPLICIT INTEGER,
- ipID [5] IMPLICIT Counter OPTIONAL
- }
-
- OBJECT: EgpParam
-
- Type: SET
-
- Definition: See above.
-
- The definition of the fields of the dictionary are given below. All
- the definitions are taken from RFC-904.
-
-
- OBJECT: p1
-
- Type: INTEGER
-
- Definition: Minimum interval acceptable between successive Hello
- commands received.
-
- Operations on Object: The defaults except as noted below.
-
- SET: The set command is optionally defined on this object.
-
- OBJECT: p2
-
- Type: INTEGER
-
- Definition: Minimum interval acceptable between successive Poll
- commands received.
-
- Operations on Object: The defaults except as noted below.
-
- SET: The set command is optionally defined on this object.
-
-
- OBJECT: p3
-
-
-
- Partridge & Trewitt [Page 57]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Type: INTEGER
-
- Definition: Interval between Request or Cease command
- retransmissions.
-
- Operations on Object: The defaults except as noted below.
-
- SET: The set command is optionally defined on this object.
-
-
- OBJECT: p4
-
- Type: INTEGER
-
- Definition: Interval during which state variables are maintained in
- the absence of commands or response in the Down and Up states.
-
- Operations on Object: The defaults except as noted below.
-
- SET: The set command is optionally defined on this object.
-
-
- OBJECT: p5
-
- Type: INTEGER
-
- Definition: Interval during which state variables are maintained in
- the absence of commands or response in the Acquisition and Cease
- states.
-
- Operations on Object: The defaults except as noted below.
-
- SET: The set command is optionally defined on this object.
-
-
- OBJECT: ipID
-
- Type: Counter
-
- Definition: The next IP packet ID identifier to be used by the EGP
- code.
-
- Object Status: Required if the EGP code generates its own IP
- identifiers.
-
-
- The IpTransportLayer Dictionary: EgpValues/EgpStats
-
-
-
-
- Partridge & Trewitt [Page 58]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The EgpStats dictionary keeps statistics about the use of EGP on
- this entity. The form of the dictionary is shown below.
-
- EgpStats ::= SET {
- inputPktCount [1] IMPLICIT Counter,
- inputPktErrors [2] IMPLICIT Counter,
- inputPktTypes [3] IMPLICIT Histogram OPTIONAL,
- outputPktCount [4] IMPLICIT Counter,
- outputPktErrors [5] IMPLICIT Counter,
- outputPktTypes [6] IMPLICIT Histogram OPTIONAL,
- egpTraffic [7] IMPLICIT TrafficMatrix OPTIONAL
- }
-
-
- OBJECT: EgpStats
-
- Type: SET
-
- Definition: See above.
-
-
- The definitions of the objects in this dictionary are given below.
-
-
- OBJECT: inputPktCount
-
- Type: Counter
-
- Definition: The number of EGP packets received including those that
- proved to be in error.
-
-
- OBJECT: inputPktErrors
-
- Type: Counter
-
- Definition: The number of EGP packets received which proved to be
- in error. This value subtracted from inputPktCount should give
- the number of valid EGP packets received.
-
-
- OBJECT: inputPktTypes
-
- Type: Histogram
-
- Definition: A histogram of types of valid EGP messages received.
- The histogram histValue field contains the message type number,
- and the histCount field contains the number of messages of
-
-
-
- Partridge & Trewitt [Page 59]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- this type which have been received.
-
- Object Status: Useful.
-
-
- OBJECT: outputPktCount
-
- Type: Counter
-
- Definition: The total number of EGP packets that the entity
- attempted to send (including those that failed due to lack of
- buffers, a missing route or other transient transmission
- problems).
-
- OBJECT: outputPktErrors
-
- Type: Counter
-
- Definition: The number of EGP packets which the entity could not
- send due to transmission problems such as the lack of buffers,
- a missing route or other transient transmission problems.
- This value is not required to include errors which the EGP
- layer could not reasonably be expected to detect such as
- damage to the packet in transit. Subtracting this value from
- the outputPktCount field should give the number of EGP packets
- the entity believes it successfully sent.
-
-
- OBJECT: outputPktTypes
-
- Type: Histogram
-
- Definition: A histogram of EGP messages types sent, including those
- that later failed to be transmitted. The histogram histValue
- field contains the message type number, and the histCount field
- contains the number of messages of this type which have been sent.
-
- Object Status: Useful.
-
-
-
- OBJECT: egpTraffic
-
- Type: TrafficMatrix
-
- Definition: All EGP traffic which has originated on this machine.
- The source address in the traffic matrix should be the interface
- from which the packet was sent. The destination is the address
-
-
-
- Partridge & Trewitt [Page 60]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- to which the packet is to finally be delivered (not an
- intermediate hop).
-
- Object Status: Useful.
-
-
- The IpTransportLayer Dictionary: EgpValues/EgpPeer
-
- The egpPeerData field of the EgpValues dictionary is a set of
- EgpPeer structures which contain the state variables for a
- particular EGP neighbor. The form of the EgpPeer structure is shown
- below.
-
- EgpPeer ::= SET {
- r [0] IMPLICIT Counter,
- s [1] IMPLICIT Counter,
- t1 [2] IMPLICIT INTEGER,
- t2 [3] IMPLICIT INTEGER,
- t3 [4] IMPLICIT INTEGER,
- m [5] IMPLICIT BOOLEAN,
- timer1 [6] IMPLICIT INTEGER,
- timer2 [7] IMPLICIT INTEGER,
- timer3 [8] IMPLICIT INTEGER,
- addr [9] IMPLICIT IpAddress
- }
-
-
- OBJECT: EgpPeer
-
- Type: SET
-
- Definition: The state information for a given EGP neighbor.
-
- The definition of each field is given below.
-
-
- OBJECT: r
-
- Type: Counter
-
- Definition: The receive sequence number as defined in RFC-904.
-
-
- OBJECT: s
-
- Type: Counter
-
- Definition: The send sequence number as defined in RFC-904.
-
-
-
- Partridge & Trewitt [Page 61]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: t1
-
- Type: INTEGER
-
- Definition: The interval between Hello command retransmissions as
- defined in RFC-904.
-
- OBJECT: t2
-
- Type: INTEGER
-
- Definition: The interval between Poll command retransmissions as
- defined in RFC-904.
-
- OBJECT: t3
-
- Type: INTEGER
-
- Definition: The interval during which neighbor-reachability
- indications are counted, as defined in RFC-904.
-
- OBJECT: m
-
- Type: BOOLEAN
-
- Definition: The Hello Polling mode. True if in active mode, false
- if in passive mode.
-
- Operations on Object: The defaults except as noted below.
-
- SET: Optionally defined to change the Hello Polling mode.
-
- OBJECT: timer1
-
- Type: INTEGER
-
- Definition: The value of timer 1 as defined in RFC-904.
-
-
- OBJECT: timer2
-
- Type: INTEGER
-
- Definition: The value of timer 2 as defined in RFC-904.
-
-
- OBJECT: timer3
-
-
-
-
- Partridge & Trewitt [Page 62]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Type: INTEGER
-
- Definition: The value of timer 3 as defined in RFC-904.
-
-
- OBJECT: addr
-
- Type: IpAddress
-
- Definition: The IP address of the neighbor.
-
- The IpTransportLayer Dictionary: UdpValues
-
- The UdpValues dictionary stores all information on the User Datagram
- Protocol, defined in RFC-768. The format of the dictionary is shown
- below.
-
- UdpValues ::= [17] IMPLICIT SET OPTIONAL {
- ipID [0] IMPLICIT Counter OPTIONAL,
- [1] IMPLICIT UdpStats,
- udpPortData [2] IMPLICIT SET of udpPort
- }
-
- OBJECT: UdpValues
-
- Type: SET
-
- Definition: See above.
-
- Object Status: Implementation of this dictionary is required if
- the entity supports UDP.
-
- The fields of this dictionary are given below.
-
- OBJECT: ipID
-
- Type: Counter
-
- Definition: The next IP packet ID identifier to be used by the UDP
- code.
-
- Object Status: Required if the UDP code generates its own IP
- identifiers.
-
-
- The IpTransportLayer Dictionary: UdpValues/UdpStats
-
- The UdpStats dictionary stores general information about the
-
-
-
- Partridge & Trewitt [Page 63]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- behavior of the UDP protocol on the entity. The format of the
- dictionary is shown below.
-
- UdpStats ::= SET {
- inputPkts [0] IMPLICIT Counter,
- inputPktErrors [1] IMPLICIT Counter,
- outputPkts [2] IMPLICIT Counter,
- }
-
- OBJECT: UdpStats
-
- Type: SET
-
- Definition: See above.
-
- Object Status: Encouraged.
-
- The fields in this dictionary are defined below.
-
-
- OBJECT: inputPkts
-
- Type: Counter
-
- Definition: The total number of UDP packets received at this entity
- including any errors.
-
- Object Status: Required if the UdpStats dictionary is implemented.
-
-
- OBJECT: inputPktsErrors
-
- Type: Counter
-
- Definition: The number of UDP packets which could not be delivered
- because of format errors, data corruption or because there was no
- application at the destination port.
-
- Object Status: Required if the UdpStats dictionary is implemented.
-
-
- OBJECT: outputPkts
-
- Type: Counter
-
- Definition: The total number of UDP segments sent from this entity.
-
- Object Status: Required if the UdpStats dictionary is implemented.
-
-
-
- Partridge & Trewitt [Page 64]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The IpTransportLayer Dictionary: UdpValues/udpPortData
-
- The udpPortData structure stores information about individual UDP
- applications. The udpPortData is represented as a set of records,
- udpPorts, which track the behavior of individual ports. The format
- of both structures are shown below.
-
- udpPortData [1] IMPLICIT SET of UdpPort
-
- UdpPort ::= [0] IMPLICIT SET {
- localAddress [0] IMPLICIT IpAddress,
- localPort [1] IMPLICIT INTEGER,
- foreignAddress [2] IMPLICIT IpAddress OPTIONAL,
- foreignPort [3] IMPLICIT INTEGER OPTIONAL,
- maxPktSize [4] IMPLICIT INTEGER,
- pktsRcvd [5] IMPLICIT Counter,
- octetRcvd [6] IMPLICIT Counter OPTIONAL,
- pktsSent [7] IMPLICIT Counter,
- octetSent [8] IMPLICIT Counter OPTIONAL,
- }
-
- OBJECT: udpPortData
-
- Type: SET of udpPort
-
- Definition: See above.
-
-
- OBJECT: UdpPort
-
- Type: SET
-
- Definition: See above.
-
- Operations on Object: The defaults except as noted below.
-
- GET-MATCH. Defined on any combination of the values of
- localAddress, localPort, foreignAddress and foreignPort.
- Returns all ports which match the template.
-
- The meaning of the individual fields of the udpPort record are given
- below.
-
-
- OBJECT: localAddress
-
- Type: IpAddress
-
-
-
-
- Partridge & Trewitt [Page 65]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Definition: The local IP address of the port. May be the default
- IP address if records are accepted from any interface.
-
-
- OBJECT: localPort
-
- Type: INTEGER
-
- Definition: The local port number.
-
-
- OBJECT: foreignAddress
-
- Type: IpAddress
-
- Definition: Some UDP implementations permit applications to specify
- the remote address from which packets will be accepted. In such
- implementations, this field may be used to return the remote IP
- address. If this value is set to the default IP address, then
- packets from any host are accepted. The default IP address
- indicates that the application has not specified the remote
- address (but could if it chose).
-
- Object Status: Required in entities which permit applications to
- specify the remote address.
-
-
- OBJECT: foreignPort
-
- Type: INTEGER
-
- Definition: Some UDP implementations permit applications to specify
- the remote address from which packets will be accepted. In such
- implementations, this field may be used to return the remote
- port. If this value is set to 0, packets from any remote port
- are accepted.
-
- Object Status: Required in entities which permit applications to
- specify the remote port.
-
- OBJECT: maxPktSize
-
- Type: INTEGER
-
- Definition: The maximum UDP packet size, if any, supported by this
- host.
-
- Object Status: Required if there is a limit on the UDP packet size.
-
-
-
- Partridge & Trewitt [Page 66]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- OBJECT: pktsRcvd
-
- Type: Counter
-
- Definition: The total number of packets received on this port during
- the lifetime of this application (i.e., application which opened
- this port).
-
-
- OBJECT: octetsRcvd
-
- Type: Counter
-
- Definition: The total number of octets received at this port.
-
-
- OBJECT: pktsSent
-
- Type: Counter
-
- Definition: The total number of packets sent on this port during the
- lifetime of this application (i.e., the application which opened
- this port).
-
-
- OBJECT: octetsSent
-
- Type: Counter
-
- Definition: The total number of octets sent on this port during the
- lifetime of this application (i.e., the application which opened
- this port).
-
-
- The IpTransportLayer Dictionary: HmpValues
-
- The HmpValues dictionary stores all information on the Host
- Monitoring Protocol, defined in RFC-869. Since HEMS is designed to
- replace HMP, the definition of this dictionary has been deferred
- until a clear need for it is demonstrated.
-
-
- The IpTransportLayer Dictionary: RdpValues
-
- The RdpValues dictionary stores all information on the Reliable
- Data Protocol (RDP). Since RDP is currently being tested and
- revised, the definition of this dictionary is left for further
- study.
-
-
-
- Partridge & Trewitt [Page 67]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- The IpTransportLayer Dictionary: NetbltValues
-
- The NetbltValues dictionary stores all information on the Network
- Block Transfer protocol. Since Netblt is currently being tested
- and revised, the definition of this dictionary is left for further
- study.
-
-
- The IpApplications Dictionary
-
- The IpApplications dictionary stores information about networking
- applications whose operations may affect the proper operation of
- the network. Examples of such applications might be domain
- nameservers or distributed routing agents (such as gated or
- routed). The definition of this dictionary is left for further
- study.
-
-
- NOTES ON RETRIEVAL OF OBJECTS
-
- It is assumed in this system that the query processor is only one
- of many concurrently running processes on an entity, and that the
- operations of the other processes may affect the values of the
- objects managed by the query processor. To permit this
- concurrency, the query processor is not required to keep the values
- frozen during the execution of a query. As a result, related
- values may change during the course of the query's execution.
- Applications should be prepared for this possibility.
-
- In several places, specific mathematical relations between objects
- have been specified, for example, that object X minus object Y
- should yield some well-defined value. Note that in many cases,
- objects X and Y are roll-over counters, in which case these
- relations are only valid modulo the precision of the counter. This
- is acceptable. The relationships are only intended to clarify the
- association between objects.
-
-
- EVENTS
-
- In the remainder of this memo we present the format and definition
- of event messages which are unsolicited updates sent from entities
- to management centers.
-
- This section needs much further work. The authors provide this
- section to illustrate how the trap mechanism works. However, much
- more research must be done into the questions of what events need
- to be reported, and what information they must carry with them
-
-
-
- Partridge & Trewitt [Page 68]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- before this section can be completed. The authors welcome any
- advice from the community on this subject.
-
-
- Format of Event Messages
-
- Event messages have the same format as replies; they are a sequence
- of objects. The only difference between a event message and a
- regular reply to a query is that the event message is labelled as a
- event in the HEMP message header and the first object in the event
- message is a special event leader describing the event. All
- objects after the event message are standard objects stored by the
- entity which might be useful to a monitoring center in
- understanding the machine state which caused the event. Each event
- has a certain number of objects that it must return. Additional
- objects may be returned by loading instructions into the
- eventExecution buffer of the relevant eventEntry.
-
- The format of the event leader is shown below:
-
- EventLeader ::= [APPLICATION 1024] IMPLICIT SEQUENCE {
- eventCode INTEGER,
- eventIndex INTEGER,
- eventThreshold INTEGER,
- eventTime TimeStamp,
- eventDescr IA5STRING
- }
-
-
- The eventCode is a number which indicates the type of event. The
- eventCodes are defined below.
-
- The eventIndex is an implementation specific value. It is
- considered good practice to make sure that a particular event is
- only generated in one place. It may be the case that certain HEMS
- generic events (for example, "no buffer space") may be generated by
- more than one place in an entity's code. To allow implementors and
- network managers to determine where the event is actually being
- generated, implementors should make sure that a distinct eventIndex
- is assigned to each location in the code that generates a
- particular event.
-
- The eventThreshold is the value of the event threshold when the
- event was sent.
-
- The eventTime indicates when the trap was generated.
-
- The eventDescr is a text string which describes the event. This
-
-
-
- Partridge & Trewitt [Page 69]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- description should explain the general problem (e.g., "no buffer
- space") and may also, optionally, include additional information
- about why this particular event was generated (e.g., "could not
- send ICMP redirect").
-
-
- Event Definitions
-
- The remainder of this memo presents a few generic events, which are
- presented for illustration only. Implementors interested in
- supporting events should contact the authors to help work out a
- more comprehensive set of definitions.
-
- The format of the event definitions is:
-
- EVENT CODE: The event code number.
-
- Definition: Defines the event.
-
- Related Objects: The list of related objects which *must* be
- returned following the event header. All objects should be
- returned as fully qualified objects (with ASN.1 codes tracing
- a complete path from the root object dictionary). If no
- objects are specified, then no related objects are required.
-
- Event Status: Events are either required of all conforming
- implementations, required if the entity supports a
- particular feature (e.g., TCP events) or optional.
-
- Notes: Any additional notes about the event.
-
-
- List of Events
-
-
- The next few event codes are for system (as opposed to more
- network oriented) events.
-
- EVENT CODE: 0
-
- Definition: Unused
-
-
- EVENT CODE: 1
-
- Definition: The entity has rebooted.
-
- Related Objects: An INTEGER which is the highest HEMP
-
-
-
- Partridge & Trewitt [Page 70]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- messageID reached by the trap system before the system
- crashed.
-
- EVENT CODE: 2
-
- Definition: The entity is about to go into test mode.
-
-
- EVENT CODE: 3
-
- Definition: The entity is about to reset.
-
-
- EVENT CODE: 4
-
- Definition: The entity is about to reboot.
-
-
- EVENT CODE: 5
-
- Definition: The entity is about to halt.
-
-
- EVENT CODE: 6
-
- Definition: The system is close to depleting its packet buffer
- space.
-
- Event Status: optional
-
-
- EVENT CODE: 7
-
- Definition: The system has depleted its packet buffer space.
-
-
- EVENT CODE: 8
-
- Definition: The system has depleted a non-packet buffer space.
-
- Note: The two trap codes above do not deal neatly with
- systems which have multiple buffer pools, each of which
- may be depleted separately, with very different effects
- on the entity.
-
-
- The next set of event codes apply to events related to network
- interfaces.
-
-
-
- Partridge & Trewitt [Page 71]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- EVENT CODE: 1024
-
- Definition: The given interface has just come up.
-
- Related Objects: The InterfaceData structure for the
- interface.
-
- EVENT CODE: 1025
-
- Definition: The given interface has just been taken down.
-
- Related Objects: The InterfaceData structure for the
- interface.
-
- EVENT CODE: 1026
-
- Definition: The given interface has just gone into test mode.
-
- Related Objects: The InterfaceData structure for the
- interface.
-
- The next set of event codes are used to report IP-level errors.
-
-
- EVENT CODE: 2048
-
- Definition: Unable to route IP packet.
-
-
- EVENT CODE: 2049
-
- Definition: Bad IP checksum.
-
-
- EVENT CODE: 2050
-
- Definition: An IP packet with a bad header was received (for
- example, with a broadcast or multicast IP address as the
- source, or the wrong IP version number, or a header length
- which is too short).
-
- Related Objects: Should return the IP header of the packet.
- Note that an IP header type has not yet been defined.
-
-
- EVENT CODE: 2051
-
- Definition: Packet for unsupported IP transport protocol.
-
-
-
- Partridge & Trewitt [Page 72]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- Related Objects: Should return the IP header of the packet.
- Note that an IP header type has not yet been defined.
-
-
- EVENT CODE: 2052
-
- Definition: A stunted IP packet was received (smaller than
- the IP length says it should be).
-
- Related Objects: Should return the IP header of the packet.
- Note that an IP header type has not yet been defined.
-
-
- EVENT CODE: 2053
-
- Definition: An oversize IP packet was received (larger than
- the IP length says it should be).
-
- Related Objects: Should return the IP header of the packet.
- Note that an IP header type has not yet been defined.
-
-
- EVENT CODE: 2054
-
- Definition: A good IP packet was discarded (usually to free
- up buffer space).
-
- Related Objects: Should return the IP header of the packet.
- Note that an IP header type has not yet been defined.
-
-
- EVENT CODE: 2055
-
- Definition: An IP packet's time-to-live as expired.
-
- Related Objects: Should return the IP header of the packet.
- Note that an IP header type has not yet been defined.
-
-
- EVENT CODE: 2056
-
- Definition: This IP fragment has timed out.
-
- Related Objects: Should return the header of the fragment.
- Note that an IP header type has not yet been defined.
-
-
-
-
-
-
- Partridge & Trewitt [Page 73]
-
- RFC 1024 HEMS Definitions October 1987
-
-
- AREAS FOR FURTHER STUDY
-
- There are several parts of this document that could use additional
- study. Comments from readers are welcome.
-
- The whole event system needs thorough examination. It is not clear
- that the event control mechanism strikes the proper balance between
- sufficient flexibility to allow monitoring centers to customize
- their event stream, and keeping the basic mechanism simple.
- Further, the problem of defining generic events for all entities is
- an immense task. Finally, the system of appending required values
- after traps, followed by optional values read from the data tree
- feels a bit cumbersome. It would be nice if all values were in the
- same data space.
-
- Several readers have suggested it might make more sense to keep TCP
- connection parameters on a per-connection basis rather than
- globally.
-
- The method for specifying the TCP round-trip time algorithm needs
- to be refined. The expression syntax should be sufficiently
- general that all round-trip-time-related algorithms (e.g., those
- for time or routing protocols) can be expressed in it.
-
- Much more research could be done into what information needs to be
- gathered to effectively monitor a network.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Partridge & Trewitt [Page 74]
-
-